<h2>Why is this an issue?</h2>
<p>Procedures with a long parameter list are difficult to use because maintainers must figure out the role of each parameter and keep track of their
position.</p>
<pre>
Sub SetCoordinates(x1 As Integer, y1 As Integer, z1 As Integer, x2 As Integer, y2 As Integer, z2 As Integer) ' Noncompliant
    ' ...
End Sub
</pre>
<p>The solution can be to:</p>
<ul>
  <li> Split the procedure into smaller ones </li>
</ul>
<pre>
' Each function does a part of what the original setCoordinates function was doing, so confusion risks are lower
Sub SetOrigin(x As Integer, y As Integer, z As Integer)
   ' ...
End Sub

Sub SetSize(width As Integer, height As Integer, depth As Integer)
   ' ...
End Sub
</pre>
<ul>
  <li> Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain </li>
</ul>
<pre>
Class Point ' In geometry, Point is a logical structure to group data

    Public x As Integer
    Public y As Integer
    Public z As Integer

End Class

Sub SetCoordinates(p1 As Point, p2 As Point)
    ' ...
End Sub
</pre>
<p>This rule raises an issue when a procedure has more parameters than the provided threshold.</p>
<h3>Exceptions</h3>
<p>The rule does not count the parameters intended for a base class constructor.</p>
<p>With a maximum number of 4 parameters:</p>
<pre>
Class BaseClass

    Sub New(Param1 As Integer)
        ' ...
    End Sub

End Class

Class DerivedClass
    Inherits BaseClass

    Public Sub New(Param1 As Integer, Param2 As Integer, Param3 As Integer, Param4 As Integer, Param5 As Long)
    ' Compliant by exception: Param1 is used in the base class constructor, so it does not count in the sum of the parameter list.
        MyBase.New(Param1)
        ' ...
    End Sub

End Class
</pre>

